home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0082 / 98.txt < prev    next >
Text File  |  1997-04-16  |  11KB  |  271 lines
  1. =========================================================================
  2.  
  3. INFO-ATARI16 Digest         Thu, 25 Jan 90       Volume 90 : Issue   98
  4.  
  5. Today's Topics:
  6.              AES function appl_tplay() and appl_trecord()
  7.                        Elite! - Avoiding police
  8.             GEM, BIOS, XBIOS, GEMDOS bindings for Sozobon
  9.                       MWC (was Re: dissassembly)
  10.                               Networking
  11.                              Subscription
  12.            Where is AES entry point?!? (Please Help Me. :-)
  13. ----------------------------------------------------------------------
  14.  
  15. Date: Thu, 25 Jan 90 19:53:19 GMT
  16. From: Michael Mueller <K298027%CZHRZU1A.BITNET@CUNYVM.CUNY.EDU>
  17. Subject: AES function appl_tplay() and appl_trecord()
  18.  
  19. I'd like to use the functions appl_tplay()| & appl_trecord(). Unfortunately, I
  20. still have old ROMs of 1985 (don't ask me the TOS version). As far as I could u
  21. nderstand, these functions only work with newer TOS versions.
  22.  
  23. Does anybody know what is the bug in the old ROMs ? Is it reasonably possible t
  24. o implement these functions by soft ? Where could I get the listings (in C, ev.
  25.  in ASM) ?
  26.  
  27. N.B.: These functions allow to record every event. You can store these events,
  28. and play them back when you want. I think there was a question about it recentl
  29. y...
  30.  
  31. Michael Mueller, Brain Research Institute, Zuerich, Switzerland
  32.  
  33. ------------------------------
  34.  
  35. Date: Thu,25 Jan 90 11:02:56 GMT
  36. From: R.D.Chafer%sysc.salford.ac.uk@NSFnet-Relay.AC.UK
  37. Subject: Elite! - Avoiding police
  38. Message-ID: <25 Jan 90 11:02:56 A10326@UK.AC.SALF.C>
  39.  
  40. Even with the docking computer on SLOW, the police will not shoot while
  41. the docking computer is on (my version anyway).
  42.  
  43. Robert
  44.  
  45. ------------------------------
  46.  
  47. Date: 25 Jan 90 18:20:37 GMT
  48. From: dartvax!eleazar.dartmouth.edu@CS.BU.EDU  (Clark L. Breyman)
  49. Subject: GEM, BIOS, XBIOS, GEMDOS bindings for Sozobon
  50. Message-ID: <18829@dartvax.Dartmouth.EDU>
  51.  
  52.         What are the preferred binadings to GEM (AES/VDI), GEMDOS,
  53.         BIOS and XBIOS for Sozobon? Or is the best way to teach oneself
  54.         GEM... by writing bindings?
  55.  
  56.         Much app,
  57.         Clark
  58.  
  59. ------------------------------
  60.  
  61. Date: 25 Jan 90 18:32:50 GMT
  62. From: sjsca4!greg@uunet.uu.net  (Greg Wageman)
  63. Subject: MWC (was Re: dissassembly)
  64. Message-ID: <1990Jan25.183250.20884@sj.ate.slb.com>
  65.  
  66. Opinions expressed are the responsibility of the author.
  67.  
  68. In article <893@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes:
  69.  
  70. >> >If you're writing code that you eventually hope for
  71. >> >other people to use, don't hard-code magic numbers like 32K into your
  72. >> >screen manipulation routines. [In fact, don't even use 32K. You only
  73. >> >need, at most, 32256, to get 32000 bytes on a 256 byte boundary, eh?]
  74. >
  75. >Well -- I had to use some value when I wrote the example.  I could have
  76. >used a #define, but at the time it seemed like this would remain unchanged
  77. >for the immediate future, and we didn't want to go through all the extra
  78. >trouble (in the example) to calculate the memory needs of the new display.
  79. >(It was not a GEM example, and S.A.L.A.D. was not yet written, and even when
  80. >these two conditions are met, it is still more than a few lines of code
  81. >to figure this out in the general case for all possible future display
  82. >modes, if its possible at all.  I don't know what happens when you use
  83. >a Moniterm.)  These examples were supposed to be short and illustrate
  84. >proper use of the documented routine/function/feature, without adding
  85. >lots of extra stuff that might confuse or intimidate the novice ST programmer.
  86.  
  87. Since TOS fails to provide a system call to return you a
  88. correctly-aligned, properly-sized chunk of memory useable as display
  89. memory, it is *impossible* not to hard-code certain assumptions into
  90. the code to do this.  MWC needs no defending on this point.
  91.  
  92. >In my honest opinion, biased as it may be, the MWC manual is the single
  93. >best volume for programming the ST published to date.  It needs revision,
  94. >bugfixing, and maybe some other tweeking (new GEM examples, etc.) and
  95. >the compiler should be updated, but it is still a very good package at a
  96. >good price.
  97.  
  98. There are some occasions where it leads to more frustration than
  99. useful results, but care in marking corrections discovered through
  100. trial-and-error will eventually produce a very comprehensive manual.
  101. I consult my MWC manual first (since it's only one volume and fits
  102. comfortably in my hand), and only when something doesn't work as
  103. advertised do I break out the backup, the dreaded Developer's Docs.
  104. Since the MWC manual seems to have been written from experience rather
  105. than specs, it tends, when there is a disagreement, to be the
  106. more-frequently-correct one.
  107.  
  108. In many cases the MWC examples demonstrate important points that
  109. aren't mentioned elsewhere.  On the other hand, at least one of the
  110. examples doesn't work at all (I think it was the one that demonstrated
  111. the use of fsel_input()).  A new versions was published in the
  112. errata with version 3.0.6 of the compiler, but *it* didn't quite work,
  113. either.  These are the sorts of problems that extend the development
  114. time of what should otherwise be a quick and easy program.
  115.  
  116. However, since the wise programmer writes routines that are as general
  117. as possible, and reuses them as frequently as possible in new code,
  118. (or at least reuses code fragments) one should find the learning curve
  119. getting steeper with each project, as one discovers how to use more
  120. and more pieces of TOS properly.  This has certainly been my
  121. experience.
  122.  
  123. Copyright 1990 Greg Wageman     DOMAIN: greg@sj.ate.slb.com
  124. Schlumberger Technologies       UUCP:   ?uunet,decwrl,amdahl?!sjsca4!greg
  125. San Jose, CA 95110-1397         BIX: gwage  CIS: 74016,352  GEnie: G.WAGEMAN
  126.  Permission is granted for reproduction provided this notice is maintained.
  127.  
  128. ------------------------------
  129.  
  130. Date: 25 Jan 90 15:06:14 GMT
  131. From: cs.umn.edu!thelake!steve@ub.d.umn.edu  (Steve Yelvington)
  132. Subject: Networking
  133. Message-ID: <0025900906143026@thelake.mn.org>
  134.  
  135. [In article <9001250807.AA00801@ucbvax.Berkeley.EDU>,
  136.      K331672@AEARN.BITNET (Gerfried Klein) writes ... ]
  137.  
  138. >
  139. >      Hi all |
  140. >
  141. > Please could somebody tell me how to reach the CI$ network from BITNET ?
  142. > Or is there a better way to contact ANTIC via e mail ?
  143. >
  144. > Hey folks, it would be a wonderfull thing if someone could sommon the
  145. > networking information (which networks are reachable, archive-hosts, ..)
  146. > so that beginners in networking could fetch this info.
  147. > But maybe there is one out there, would be fine |
  148. >
  149.  
  150.   Convert the CIS user ID from the form 7xxxx,yyy to 7xxxx.yyy (replace
  151.   the comma with a dot).
  152.  
  153.   Then mail to the following address:
  154.  
  155.   7xxxx.yyy%compuserve.com@saqqara.cis.ohio-state.edu
  156.  
  157.   The appropriate newsgroup for questions of this sort is comp.mail.misc.
  158.   John Chew posts a (mostly monthly) guide to internetwork mailing; I
  159.   received the most recent copy about three days ago, so it should be
  160.   available on your system.
  161.  
  162. --
  163.    Steve Yelvington at the (thin ice today*) lake in Minnesota
  164.    UUCP path: ... umn-cs.cs.umn.edu!thelake!steve
  165.  
  166.    *16 cars through the ice so far this year! Yes, you, too, can
  167.     have that sinking feeling....
  168.  
  169. ------------------------------
  170.  
  171. Date: 25 Jan 90 18:58:51 GMT
  172. From:
  173.  swrinde!zaphod.mps.ohio-state.edu!uwm.edu!mrsvr.UUCP!jupiter.uucp!krieg@ucsd.ed
  174.  u  (Andrew Krieg)
  175. Subject: Subscription
  176. Message-ID: <1953@mrsvr.UUCP>
  177.  
  178. SUBSCRIBE INFO-A16
  179. --
  180. =========================================================================
  181. =       Andrew Krieg                            The Marvel Historian    =
  182. =               G.E. Medical Systems - CT - New Berlin, WI              =
  183. =                    USENET: krieg@jupiter.med.ge.com                   =
  184. =========================================================================
  185. =               "Holy one track Batcomputer mind!" - Robin              =
  186. =========================================================================
  187.  
  188. ------------------------------
  189.  
  190. Date: 25 Jan 90 15:23:12 GMT
  191. From: cs.umn.edu!thelake!steve@ub.d.umn.edu  (Steve Yelvington)
  192. Subject: Where is AES entry point?!? (Please Help Me. :-)
  193. Message-ID: <0025900923123027@thelake.mn.org>
  194.  
  195. [In article <10489@saturn.ucsc.edu>,
  196.      rome@ucscb.UCSC.EDU writes ... ]
  197.  
  198. >       I was up all last night trying to call a file selector using
  199. > assmebler code mixed with a C source file.
  200. >
  201. >       I am trying to send the extended information to the AES file
  202. > selector function that is picked up and utilized by LGF's File Selector.
  203. >
  204. >       In the documentation for the LGF FS, there is in-line assembler
  205. > code provided to type into a C program to get it to call the file selector.
  206. >
  207. >       One of the instructions is "bsr  AES" ... Well, Laser C does
  208. > not seem to have any constant "AES" defined.
  209. >
  210. >       Does anyone know the absolute memory entry point for the AES?
  211. >       Can anyone help?  We'll see.
  212. >
  213.  
  214. It doesn't work that way. AES is entered through a 68000 trap, not through
  215. an address.
  216.  
  217. I think Charles Johnson has made some unwarranted assumptions about what
  218. can be found in the C bindings for the AES. The label "aes" may or may not
  219. be defined. I don't know how Laser does it.
  220.  
  221. The following information may help you determine what he is looking for.
  222.  
  223. The AES is invoked by:
  224.  
  225.         * copying the arguments to the function (file selector call, for
  226.         example) into "mailboxes." There are arrays of mailboxes, typically
  227.         labeled control[], global[], int_in[], int_out[], addr_in[], and
  228.         addr_out[]. I don't recall their sizes. The args are copied from
  229.         left to right in a C binding. Integers go into int_in[];
  230.         addresses (such as pointers to strings) go into addr_in[], etc.
  231.  
  232.         * the control[] mailbox array is stuffed with an AES opcode
  233.         number (control[0]). Three magic numbers are stuffed into
  234.         control[1] through [3]. These numbers tell the AES how many
  235.         integers and addresses to expect. The numbers are contained in
  236.         the dlibs crystal.s module, if you're interested.
  237.  
  238.         * an array of 6 addresses is loaded with the addresses of
  239.         each of the mailbox arrays (control, global, etc., as above).
  240.         This array typically is called the AES parameter block.
  241.  
  242.         * The address of the AES parameter block is loaded into d1.
  243.  
  244.         * The magic number 200 is loaded into d0.
  245.  
  246.         * trap #2 kicks AES into action.
  247.  
  248. I think I've got all this right, but no promises. :-) I wrote some AES
  249. bindings in C for Sozobon before GEMFAST came out, and this is the
  250. strategy that I figured out from various published (non-Atari) documents
  251. and code snippets.
  252.  
  253. --
  254.    Steve Yelvington at the (thin ice today*) lake in Minnesota
  255.    UUCP path: ... umn-cs.cs.umn.edu!thelake!steve
  256.  
  257.    *16 cars through the ice so far this year! Yes, you, too, can
  258.     have that sinking feeling....
  259.  
  260. ------------------------------
  261.  
  262. Date: Thu, 25 Jan 90 09:12:00 -0900
  263. From: <AXCSH%ALASKA.BITNET@CUNYVM.CUNY.EDU>
  264.  
  265. UNSUBSCRIBE Chris Hamman
  266.  
  267. ------------------------------
  268.  
  269. End of INFO-ATARI16 Digest V90 Issue #98
  270. ****************************************
  271.